IsRetrySyncAvailable

Definition:

IsRetrySyncAvailable()

 

Description:

Check whether the Digitise Apps Client received a response from the App Server to the last call to Synchronise or SyncDataSource.

 

Platforms:

All

 

Parameters:

none

 

Returns:

True, "True", 1 or "1"

A response HAS NOT been received from the Server or the Server does not support RetrySync functionality (e.g. because you are connecting a newer version of the Digitise Apps Client to an older App Server from Digitise Apps' predecessor MX, pre-MX - 2020 Vision Edition).

If you are checking the return value, you can check for any of the values listed here.

 

False, "False", 0 or "0"

A response HAS been received from the Server or the Server does not have a response waiting to be forwarded to the Client.

If you are checking the return value, you can check for any of the values listed here.

 

Notes:

  • IsRetrySyncAvailable can be used in conjunction with the RetrySync Method to attempt to complete a data upload, initiated using the Synchronise or SyncDataSource Methods, when the App Server is unable to send the result of the data transfer back to the Digitise Apps Client because the connection between the Client and the Server fails. IsRetrySyncAvailable allows you to check whether the App Server was able to return the result of the last data upload and, if not, RetrySync allows you to request it to send the result. The result will also include the download data, if any, specified by the original data transfer request.

    These Methods are only relevant after a call to either Synchronise or SyncDataSource, although we recommend the use of the newer Synchronise Method over SyncDataSource, where possible, as it provides more advanced features.

     

    Data records are marked as modified by calling UpdateCurrentRecord. If you then call Synchronise, including upload data, the Digitise Apps Client sends any modified records for the Data Sources specified to the App Server and then waits for a response from the Server to say the transfer has been completed. If the original call includes data to be downloaded as well as uploaded, the download data will be included in the Server's response. If the Server has successfully updated the remote Data Source, the Client will remove the modified flag from the uploaded records so that the next time the Data Source is uploaded, these records won't be included (unless they are modified again in between). If you have called Synchronise specifying an async transfer, the transfer occurs in background and the user can continue to use the app. For Synchronise in sync mode, the Client stops the app until the response has been received.

    The App Server waits until it has received all the data from the Digitise Apps Client before it attempts to send the data on to the remote Data Source. If the connection drops before the Server has received all the data, the Client will display an error if data error reporting is enabled, otherwise you can access the error using GetLastError or GetLastDataError. In this situation, you would need to call Synchronise again and resend the records. (Data error reporting is turned OFF using the SetDataErrorOn Method or On Error GoTo 0 statement and turned ON using the SetDataErrorOff Method or On Error Resume Next statement.)

    If the App Server receives all the modified records from the Client but is unable to successfully forward some or all of them to the remote Data Source, it will return one or more error messages to the Client. An error message may be displayed if Data Error Reporting is enabled, otherwise you can access the error(s) using GetLastError or GetLastDataError. In this situation, the state of the local database and remote data source can vary, e.g. depending upon whether the Use SQL Transaction Property is configured to roll back changes. For this reason, you should include appropriate checks within your app to handle such a situation and provide for the data transfer to be restarted if necessary.

    Another potential issue may occur if the Server receives all the modified records from a Client and successfully updates the remote Data Source but is then unable to send the result back to the Client because the connection between them has dropped. If the Client later resends the modified records the Server will forward them to the remote Data Source again, which may result in duplicate records being added to the remote Data Source.

    In this situation, if you called Synchronise in async mode, the Client will automatically continue to attempt to reconnect to the Server, at increasing time intervals, until the app is closed, the transfer is cancelled, using the CancelTransaction Scripting Method, or the connection is re-established. If the transfer is cancelled, resending the data shouldn't adversely affect the remote Data Source. If the app is closed, however, restarting the transfer may result in duplicate records in the remote Data Source. On the other hand, if the connection is re-established whilst the Client is attempting to reconnect, the transfer should complete successfully.

    If you called Synchronise in sync mode, the Client will attempt to reconnect to the App Server for a certain number of times after which it will stop trying. If the connection is re-established during these attempts, the transfer will complete. If the transfer is unable to complete, subsequently resending the data, once a connection has been re-established, may result in duplicate records in the remote Data Source. The number of times the Server will attempt to connect is specified, along with other options including the time interval between attempts and how long the server should retain the results of the last upload, under the Advanced link in the Server Properties in App Manager.

    In this last situation, IsRetrySyncAvailable allows you to check whether the Client has received a response from the Server for the last data transfer using Synchronise or SyncDataSource and, if not (IsRetrySyncAvailable returns True or 1), you can call RetrySync to request the Server to send it again. In this way you can avoid resending data which has already been successfully uploaded.

    If the original upload is made using SyncDataSource, instead of Synchronise, there may or may not be data to download after the upload, depending upon the value of the Load After Sync Property. Either way, the response from the App Server will include the results of the upload, which inform the Client whether to remove the modified flag from uploaded records. As described for Synchronise calls above, you can use IsRetrySyncAvailable and RetrySync to check whether a response has been received from the App Server and, if not, request it to try sending the response again.

  • IsRetrySyncAvailable will check whether a response was received for the specific instance of the app making the IsRetrySyncAvailable call.

  • You can specify a timeout period (default 1 hour) for the App Server to retain its response after being unable to forward it to the Digitise Apps Client under the Advanced link in the Server Properties in App Manager. When this timeout expires, it will delete its stored response, IsRetrySyncAvailable will then return False and you cannot use RetrySync to obtain the missed response.

    If the connection is re-established and the transfer is able to complete before the timeout period expires, the App Server will again delete its response and IsRetrySyncAvailable will then return False and RetrySync will return 0.

    Likewise, if a call to Synchronise or SyncDataSource completes successfully without any issues, the App Server doesn't retain a record of the response and a call to IsRetrySyncAvailable will return False and a call to RetrySync will return 0.

  • If you make another call to Synchronise or SyncDataSource after a failed call to either of these Methods, IsRetrySyncAvailable will return the result of this second call and the result from the first call will be lost. You might, therefore, want to routinely call IsRetrySyncAvailable before any call to Synchronise or SyncDatasource.

  • If the App Server is unable to send its response to the Digitise Apps Client for a call to Synchronise in async mode, and you cancel the data transfer using CancelTransaction, IsRetrySyncAvailable will return False. However, if, in this situation, you stop the transfer by closing the Digitise app or the Digitise Apps Client, after reloading the app, IsRetrySyncAvailable may return True and you may be able to use RetrySync to retrieve the Server's response.

  • IsRetrySyncAvailable will only work where both App Server and Client/Standalone App support this feature, i.e. each must be MX - 2020 Vision Edition or a Digitise Apps version.


See also:

RetrySync

Synchronise

SyncDataSource

UpdateCurrentRecord

SetDataErrorOn

SetDataErrorOff

Error Handling

GetLastError

GetLastDataError